SuperHack/SuperHack CD.bin/CODING/CPP/HUGEAR.ZIP/README.TXT

Text File | 1994-11-27 | 6KB | 108 lines

This is an implementation of huge arrays and huge vectors using templates and
the Borland container class library. Here are the features:

1: The code is for 16 bit platforms, DOS, DPMI16, WINDOWS, for Borland C++ 4.02 .

2: Huge arrays provide arrays of items that go beyond 64K in the 16 bit world
   to access all of available memory.

3: The code is a direct modification of Borland's arrays.h, vectimp.h, and
   alloctr.h . These files are harrays.h, hvectimp.h, and halloctr.h . To
   use huge arrays, just include the file harrays.h in your source. To use
   huge vectors just include the file hvectimp.h in your source. The other
   file(s), as well as files in Borland's container class library will be
   included automatically.

4: The names for the huge arrays and the huge vectors are the exact same
   names you would use for normal arrays and vectors in Borland's container
   class library but with the word "Huge" preceding the Array of Vector in the
   name. For instance instead of instantiating a TArrayAsVector object you
   would instantiate a THugeArrayAsVector object. Instead of instantiating
   a TVectorImp you would instantiate a THugeVectorImp. The same naming
   conventions go for the array and vector iterators. The naming conventions
   for Borland 3.1, accessible by defining BI_OLDNAMES before including the
   container class library header file(s), is not supported for this
   implementation.

5: There is no conflict between this huge array implementation and any of the
   other container class libraries.

6: Both direct and indirect arrays and vectors are fully supported.
   For direct arrays you are still adding just the object, not a huge object.
   For the indirect arrays and vectors you are still passing in normal pointers
   to objects, not huge pointers to these objects. It is the array or
   vector that is "huge" not the objects themselves.

7: For both direct and indirect objects the [] operator to access these objects
   return a "huge reference" rather than just a reference. For direct containers
   this is a huge reference to the actual object ie. T __huge & , while for
   indirect containers this is a huge reference to the pointer to the object
   ie. T * __huge & . This parallels the normal container classes case.

8: For direct containers, other functions other than the [] operator that pass back
   references or pointers to the containers now pass back huge references or
   huge pointers to these containers. These include the things like the
   ++ iterator operators, the FirstThat and LastThat functions etc. This
   parallels the normal container classes.

9: For indirect containers, other functions other than the [] operator above
   pass back the actual pointer to the object. This is a normal pointer, not
   a huge pointer ( see 6: above ). This parallels the normal container classes.

10: Sizes for these arrays and vectors are no longer int or unsigned int
   but long and unsigned long respectively. Functions that used to pass back the
   2 byte quantities now pass back the 4 byte quantities ie. ArraySize and
   GetItemsInContainer . Array and vector sizes are initialized
   in terms of long and unsigned long sizes rather than int and unsigned int
   respectively.

11: This implementations uses internally the standard library functions
   "farmalloc" and "farfree" whereas the standard container classes use the
   C++ "new" and "delete" operators. The "new" and "delete" operators could
   not be used since they take "size_t" sizes and "size_t" in the 16 bit
   world is an unsigned int. You do not have to be concerned about this
   unless you use your own managed memory array or vector, in which case
   look at halloctr.h . Otherwise this knowledge is transparent.

12: Because "farmalloc" and "farfree" is used in place of "new" and "delete"
   an exception is thrown if memory could not be allocated. The name of the
   exception is THugeXAllocation . It is located in halloctr.h, which is
   automatically included when you include harrays.h or hvectimp.h . The
   exception has one public member, "unsigned long size", which is the size
   of the allocation on which farmalloc failed. The exception could occur
   when:

         You initially allocate an array or vector of a certain size in the
             constructor.
         Use the copy constructor to construct an array or vector from another
             array or vector.
         Assign an array or vector to your present array or vector.
         Add or AddAt an object to your array or vector.

   You can catch this exception and deal with as you like in the normal way.

13: This is NOT, repeat NOT, an official implementation by Borland and is in
   no way connected with them. My name is Edward Diener, my Compuserve ID is
   70304,2632 . I will be happy to hear of any problems you have with this
   implementation in order fix things if anything is wrong. However you are
   largely on your own when it comes to understanding huge arrays and vectors.
   I have made the implementation as transparent as possible and it parallels
   as closely as I can make it the normal array and vector container class
   implementation. You have the source code and so can modify it for your
   own purposes but please, if you re-post it for any reason for other users
   ask Borland's permission first. I have asked and received Borland's
   permission to post this code for other users. I do not have Borland 4.5
   yet so I have no idea whether this will work with Borland 4.5 . If when
   I receive 4.5 there is still no support for huge arrays and vectors I may
   do the implementation for 4.5 .

14: This was originally done because I wanted to access arrays greater than
   64K for a personal project I am doing. I am not in love with "huge"
   keywords, segmented architecture etc. I will be only too happy to move
   to the 32 bit world and leave all that nonsense behind. However I use
   Borland's Paradox Engine and Database Frameworks and am beginning to use
   the Database Engine, and both are still only for the 16 bit world. I
   eagerly look forward to Borland releasing their Database Engine for the
   32 bit world, hopefully for both WIN32 and DPMI32, at which time I will
   glad leave the limitations of the 16 bit world behind.